1. Technical Field of the Invention
This invention pertains to data security. More particularly, it pertains to the creation, deletion and retrieval of security connection objects and the querying of cryptographic services.
2. Background Art
It is currently state of the art of the Internet to create Virtual Private Networks (VPNs) using Internet Protocol Security (IPSec). However, there exists no standard nor current implementation for configuring and implementing the connection of systems in this Internet environment, such as between systems using the Transmission Control Protocol/Internet Protocol (TCPIP) and systems using the Internet Protocol Security (IPSec). Typically, graphical user interfaces (GUIs) are provided that configure data security policies only. There is, therefore, a need in the art to provide a connection model and GUI for configuring the connection of disparate systems, particularly in an Internet environment.
With the onset of network computing came the need to insure secure connections between networked computers. Usually companies resorted to establishing private networks to do this, and at considerable expense. However, as this trend of Network Computing continues to evolve, it is necessary to extend secure communications within the enterprise and to utilize the public networks. Driving factors include the need for mobility, company mergers and acquisitions, and the usual `improving the bottom line`. Virtual Private Networks (VPNs), in this context, allow customers to use existing private or public networks, including the Internet, to establish secure connections between other businesses, branch offices, and remote users. One problem with VPNs is they are usually implemented via proprietary techniques, such that interoperability is limited to single vendor solutions. The IETF now has working groups and draft standards which will allow a more uniform VPN solution across vendors that implement to those standards. IP Security (IPSEc) and Internet Security Association Key Management Protocol (ISAKMP) are examples of these standards and these are the standards used in the preferred embodiment of the invention.
Current systems apply static, predefined filter rules (SPD entries, in RFC2401 terms) to a system interface. When attempting to negotiate with a remote system, if the client identifiers IDci and IDcr from the remote system do not match exactly an existing filter rule, the negotiation is unsuccessful. IDci and IDcr are the identifiers for clients of Security Associations (SAs), where ci refers to client initiator and cr to client responder. An SA is an ISAKMP (sometimes referred to as the Internet Key Exchange (IKE), which defines the IPSec domain of interpretation of the ISAKMP framework) unidirectional security protocol specific set of parameters that defines the services and mechanism necessary to protect traffic between two nodes. Consequently, there is a need in the art for enabling acceptance of previously unknown IDci and IDcr values from a remote system. Further, current implementations may have a filter rule for all IP traffic between a local host and a given subnet through a remote gateway. If so, the only connection allowed is for this set of IP traffic, and if the remote host does not have a corresponding filter rule, no connection can be established. There is, therefore, a need in the art for dynamically generating, loading and managing multiple IPSec filter rules (SPD entries) for traffic between a local host and a given subnet through a remote gateway.
Current system provide ISAKMP phase I and phase II connections. A phase I connection is an ISAKMP-to-ISAKMP secure connection used to negotiate keying material for phase II connections. A phase II connection is the actual IPSec connection to secure IP datagrams. Usually, a phase I connection is managed in a similar manner to a phase II connection, in that it is initiated, refreshed, and possibly scheduled independently. There is a need, therefore, in the art for enabling ISAKMP phase II driven phase I connections, such that unnecessary IKE traffic is avoided by only creating or refreshing a phase I connection if there is an active phase II connection that currently requires it.
Currently, filter rules are written statically with pre-defined IP selectors (IP addresses, port numbers, and transport protocol). However, when dealing with a dynamically assigned IP address from a third party (such as an Internet Service Provider, or ISP), there is no way currently of knowing what IP address to configure in the rules, particularly for handling different security policies for different hosts (users). There is, therefore, a need in the art for enabling connection filter rules to be generated and loaded dynamically at negotiation time, and thus handle remote initiating hosts with dynamically assigned IP addresses.
It is a further object of the invention to provide a system and method for creating, maintaining, deleting and retrieving VPN policy objects.
It is a further object of the invention to provide a system and method for enabling acceptance of previously unknown IDci/IDcr values from a remote system.
It is a further object of the invention to provide a system and method enabling dynamic generation, load, and management of multiple IPSec filter rules.
It is a further object of the invention to provide a system and method enabling ISAKMP phase II driven phase I connections.
It is a further object of the invention to provide a system and method enabling handling of remote initiating hosts with dynamically assigned IP addresses, that may have differing security policy requirements.
It is a further object of the invention to provide a system and method providing flexibility in policy definition in the areas of dynamically-assigned IP addresses, remotely-defined ISAKMP client IDs (IDci/IDcr), and separation of ISAKMP Phase I (key management) policy information from ISAKMP Phase II (data management) policy information.
It is a further object of the invention to provide a data model for representing and abstracting IPSec/ISAKMP-based VPN configuration information for an IPSec-capable computer system in a virtual private network that (1) allows for each customer-generated customer-ordered security policy database (SPD) entry, multiple VPN connections to be dynamically established (these connections may or may not have been previously defined); (2) allows for a data- security-policy-driven approach to rekeying (via ISAKMP) where (a) the key management connection (i.e. the secure connection used to exchange keying material for the data connections) is created and maintained by security policy and on an on-demand basis by data connection activity, and (b) the key connection security policy is determined solely by the identity of the remote connection endpoint; (3) allows for dynamically establishing VPN connections with different security policies and other attributes, based solely on an unfixed IP address (e.g. a user ID)--these connections may or may not have been previously defined. This aspect is used for supporting systems with dynamically-assigned IP addresses that wish to establish a VPN connection with the local system.